A comment regarding this, at the SDK level, it's difficult to know that something as simple as Notifications.addClickListener(this) needs to be launched on a different thread than the main one; ultimately, the complexity is transferred to the developer. For example, this code also triggered the error:

initWithContext(context, ONESIGNAL_APP_ID)
if (OneSignal.isInitialized) {
    Notifications.addClickListener(this)
}

Given my lack of context when using the SDK, I initially assume that adding a listener shouldn't require the SDK to be initialized, nor should it need to be done on a non-main thread. And I least expected a failure when there was confirmation that it was initialized.

I understand that the fix solves a problem but not the cause. In my opinion, the SDK should either provide an initialization event, perhaps with a listener or something similar, to indicate when it's a good time to subscribe to things. And if certain operations must be done off the main thread, that should be the SDK's default behavior internally, providing options for advanced users to change said behavior.

Having said all this, perhaps none of this is necessary if the documentation is supplemented with examples of how to work better with the SDK following these changes.

In any case, thank you for working on the fix and constantly improving the SDK.

Starting in 5.4.0 calls such as OneSignal.Notification or OneSignal.Location would throw if they waited on the SDK into to long. This comment changes this to wait forever until init is complete, and log instead if the time is taking longer than expected. If these calls were done from the main thread an ANR is the better of two evils and the app can recover, where an uncaught throw it can not.

This commit will bring the behavior the similar behavior in 5.1.x. The only difference is you will now never see an ANR with initWithContext, however if you call other parts of the SDK from the main thread, such as OneSignal.Notification, you will continue to see ANRs, just at a different stacktrace. To avoid these ANRs completely call all other SDK methods outside of the main thread.

Please mark these functions with suspend so that we, as developers, can always see which functions need to be called as suspend functions.

A comment regarding this, at the SDK level, it's difficult to know that something as simple as Notifications.addClickListener(this) needs to be launched on a different thread than the main one; ultimately, the complexity is transferred to the developer. For example, this code also triggered the error:

initWithContext(context, ONESIGNAL_APP_ID)
if (OneSignal.isInitialized) {
    Notifications.addClickListener(this)
}

Given my lack of context when using the SDK, I initially assume that adding a listener shouldn't require the SDK to be initialized, nor should it need to be done on a non-main thread. And I least expected a failure when there was confirmation that it was initialized.

@alberto-derodrigo-spacego thanks for your feedback here, I agree that this is confusing and appending a listener shouldn't require suspend. The problem stems from that fact that accessing OneSignal.Notification requires initializing all it's dependencies before accessing anything on it. We will look into addressing this in a next major release (v6), as an app developer shouldn't have to account for this implementation detail.

In my opinion, the SDK should either provide an initialization event, perhaps with a listener or something similar, to indicate when it's a good time to subscribe to things.

The pre-5.4.0 expected pattern was to call OneSignal.initWithContext and wait until this function return successfully before calling anything else one OneSignal. In 5.4.0 the SDK initialization is more flexible, you still must call OneSignal.initWithContext first, however even if it hasn't finished yet you can call other OneSignal SDK methods from another thread.

• OneSignal.initWithContextSuspend was also added in 5.4.0 so this can be used as an alternative as well.
• ANR note - All ANRs from OneSignal.initWithContext have been completely addressed in 5.4.0, however note that all other calls, such as OneSignal.Notifications will wait for initialization. So if you were already getting ANR pre-5.4.0 you may see this simply shift to other SDK methods. To avoid those call all other SDK methods off the main thread to completely avoid the ANRs.

Please mark these functions with suspend so that we, as developers, can always see which functions need to be called as suspend functions.

@michael-winkler

OneSignal.Notifications is a property and Kotlin doesn't support suspend on properties. We are considering on adding OneSignal.getNotifications() as a function to provide this access pattern.